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Flexible Multi-Agent System Architecture 

The present invention relates to a multi-agent system (MAS) architecture, in particular 
to a multi-agent system architecture which is suitable for Open Electronic Commerce. 
5 The invention further relates to a method of, and a mediator agent for, providing 
generic role components to other agents in the MAS. 

Software agent technology is widely used in a variety of applications ranging from 
comparatively small systems such as personalised electronic mail filters to large, 

10 complex, and mission-critical systems such as air-traffic control. Multi-Agent Systems 
(MASs) are designed and implemented using multiple software agents that interact via 
messages to achieve a goal. MASs are used in the field of information service 
provision where information service providers are highly competitive and it is very 
advantageous if they can differentiate their products by providing new kinds of 

1 5 interactions amongst information customers. 

In a MAS, each agent has incomplete information or a limited capability for solving a 
problem. Therefore an agent must interact with other agents autonomously. A MAS can 
be differentiated from existing distributed object systems in that each agent 
20 autonomously detects and solves a problem using its reasoning facility minimising the 
human user's intervention. 

One of the main MAS principles concerns the separation of service provision and 
service requests amongst the distributed agents. If one agent cannot perform a task, it 
25 adopts the role of a client agent and requests assistance from another agent (acting in 
the role of server agent) which satisfies the request by executing the required service. 

Currently, interactions among multiple agents are affected by certain limitations of 
known MASs. These limitations include interoperability issues among heterogeneous 

30 agents, the semantics of the agent communication language (ACL) used which 
specifies the standard agent message structures, the allocation of tasks among 
participant agents, and the building of conversation policies (or interaction protocols 
(IPs)) etc. (For more details see Mamadou T. Kone, Akira Shimazu and Tatsuo 
Nakajima, "The state of the art in agent communication languages", in Knowledge and 

35 Information Systems (2000) 2: 259-284; and Jennings, N. R., Sycara, K., and 
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Wooldridge, M., "A roadmap of agent research and development", Autonomous Agents 
and Multi-Agent Systems, 1, 275-306, 1998. 

Interoperability is mainly concerned with enabling different agents to communicate with 
5 each other by using a standard agent communication language (ACL) and interaction 
protocols etc. Interoperability involves several areas of research such as ontology, 
content language, and ACL. Ontologies provide common representations of knowledge 
for specific domains where agent communication occurs. Content languages are 
standard expressions of domain-independent knowledge that are used together with 
1 0 ontologies to specify the content part of agent messages. 

Whilst interoperability is not an issue when all agents within the same platform use a 
predefined language, ontology, and interaction protocols to compose an ACL, this 
situation is unrealistic in an electronic commerce environment where new agents are 
15 dynamically introduced with new services. 

FIPA (The Foundation for Intelligent Physical Agents) aims to produce standards for 
the interoperation of heterogeneous software agents. FIPA has developed the FIPA 
Abstract Architecture Specification which specifies the standard architecture that 
20 heterogeneous agent platforms should comply with to be able to communicate each 
other. 

According to the FIPA Abstract Architecture Specification (for more details see FIPA 
Specifications, Foundation for Intelligent Physical Agents, 2000, 

25 http.7/www.fipa.orq/repositorv/index.html) . a server agent should register its services 
with a Directory Facilitator (DF) and client agents should contact the DF to find an 
appropriate server agent that provides the required services. The client agent creates a 
service description that contains the service name, type, protocol, ontology, and 
content language to be used for the service and uses the service description to query 

30 the DF to find suitable server agents. However, the FIPA abstract architecture 
specification is limited in that a client agent is only able to request services which are 
already known to it (for example, see Steven Wilmott, Jonathan Dale, Bernard Burg, 
Patricia Charton and Paul O'Brien, "Agentcities: A Worldwide Open Agent Network", 
Agentlink News, No. 8, Nov. 2001, available at 

35 http://www.AqentLink.orq/newsletter/8/AL-8.pdf . for more details). Moreover, whilst the 
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FIPA abstract architecture addresses the issue of providing a mechanism that allows 
interoperability between agents in a variety of heterogeneous platforms by using a 
standard message structure or content language, ontology, and interaction protocol 
(these standards can also be used within the same platform), the FIPA standards do 
5 not specify how existing agents can handle messages which include a new content 
language and/or ontology, and/or interaction protocol even if they reside on the same 
platform. 

Another issue relevant when considering interoperability is the conversation policy to 

10 be used for a multi-agent interaction. Conversation policies, also called interaction 
protocols, are predefined sequences of agent messages that guide and constrain agent 
communications for specific objectives. They are essential in complicated agent 
conversations that involve a lot of messages and many possible branches of logic and 
have been the subject of research by several parties. For example, see the earlier 

15 reference by Mamandou as well as Ren'ee Elio and Afsaneh Haddadi, "On abstract 
task models and conversation policies", in Working Notes of the Workshop on 
Specifying and Implementing Conversation Policies, pages 89-98, Seattle, 
Washington, May 1999; M. Greaves, H. Holmback, and J. Bradshaw, "What is a 
conversation policy? ", in Proc. The Workshop on Specifying and Implementing 

20 Conversation Policies, Seattle, Washington, May 1999, pp. 118-131; Scott A. Moore, 
"On conversation policies and the need for exceptions", in Working Notes of the 
Workshop on Specifying and Implementing Conversation Policies, Seattle, 
Washington, May 1999; and Jeremy Pitt and Abe Mamdani, "Communication protocols 
in multi-agent systems", In Working Notes of the Workshop on Specifying and 

25 Implementing Conversation Policies, pages 39-48, Seattle, Washington, May 1999. 

Without a conversational policy, interoperability may not be achieved between agents 
as each individual agent will find in each communication step of the interaction that 
they may need to select a message type to use to communicate, and each agent may 
30 select a different message type to use, based on their own understanding and 
implementation of the ACL semantics. It therefore is generally advisable to use 
conversation policies in all non-trivial conversations. 

One of the limitations of known MASs is that agents only use a set of known or 
35 standard conversation policies and cannot handle ad-hoc conversation policies without 
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re-implementation. The need for ad-hoc conversation policies is clear in information- 
centric agents in e-markets that are characterized by their focus on collecting, 
processing, analysing, and monitoring information. 

5 Information-centric agents, also referred to herein simply as information agents, can be 
defined as a class of autonomous agents that are closely related with information 
sources (for more details see K. Decker, A. Pannu, K. Sycara, and M. Williamson, 
"Designing behaviors for information agents", in Proc. The First International 
Conference on Autonomous Agents (AGENTS-97), Feb. 1997, pp. 404-412). For these 

10 reasons, conversations with information agents can be dependent on the nature of 
information sources. As information sources range from legacy systems to web sites, 
etc, it is not feasible to assume that in the future they will be accessible by only a few 
standard conversation policies. Even now, it has been said that existing conversation 
policies are not extensive enough to support all applications and systems (see, for 

15 example, the above reference by Moore). New policies will need to be implemented 
and present policies upgraded in the future. A conversation policy handshaking 
mechanism to allow agents to exchange ad-hoc conversation policies and interact after 
interpretation of the new conversation policy on the fly is already known in the art from 
Hyung Jun Ahn, Habin Lee, Hongsoon Yim, Sung Joo Park, "Handshaking Mechanism 

20 for Conversation Policy Agreements in Dynamic Agent Environment," First International 
Joint Conference on Autonomous Agents and Multi-Agent Systems (AAMAS 2002). 
However, this ad-hoc interaction protocol is not able to handle messages with unknown 
languages and ontologies. 

25 A service component concept for MAS has been adopted in the European 5 th 
Framework project LEAP (Lightweight Extensible Agent Platform) (see LEAP Project 
website, http://leap.crm-paris.com ). In the LEAP project, a Generic Service Component 
(GSC) construct was designed, and 22 specializations of it, covering three application 
areas (that is, knowledge management, travel management, and decentralised work 

30 co-ordination management) were produced (a subset of which were actually 
implemented) to be used in a wide variety of applications. However, whilst the main 
objective of a LEAP GSC is to provide generic service components which can be 
reused in similar applications, the GSC construct developed in the LEAP project is a 
static library that is only used when agents are developed, and which must be present 

35 when they are launched on an agent platform. Consequently, the generic service 
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components proposed by LEAP cannot be dynamically installed on to agents which are 
already running. 

In electronic commerce (eCommerce), MASs are considered to play a major role (see 
5 for example, Maes, Pattie, Guttman, R. H., and Moukas, A. G. "Agents That Buy and 
Sell", Communication of the ACM, Vol. 42, No. 3, pp.81-91, 1999). In eCommerce, 
autonomous agents can act on behalf of their human users to buy or sell products or 
services and the openness and flexibility of the MAS will affect its success. The 
eCommerce environment is dynamic in that new consumers and merchants may 

10 appear, new products and services can be introduced frequently, and sometimes the 
standard languages and transaction rules can be changed. As a result, any MAS 
implemented in an eCommerce environment needs to be flexible enough to adapt to 
these frequent changes in an eMarket settings. More specifically, a MAS for 
eCommerce should enable agents to participate, disengage, and/or transact with each 

15 other using new business rules (subject to some minimum constraints) whenever these 
new rules arise. 

In order for a known MAS to become sufficiently open and flexible for an eCommerce 
environment, all participating agents would be required to use the same content 

20 languages, ontologies, and interaction protocols in the messages they exchange. This 
is unrealistic to achieve using known MASs as this prerequisite makes it impossible for 
agents providing new services based on a new interaction protocol, ontology, or 
content language to participate in any existing MAS-based markets. To accommodate 
such an agent, the MAS would have to be re-engineered to allow existing agents to use 

25 the new content language, ontology, or interaction protocol to request and receive 
service from the new agent. 

"Multi-agent co-operation, dynamic workflow and XML for e-commerce automation' 1 by 
Qiming Chen et al, AGENTS 2000, Proceedings of the 4th International Conference on 

30 Autonomous Agents, June 3-7, 2000, Barcelona, Spain, ACM, 2000, describes a Java 
based dynamic agent infrastructure for e-commerce automation, which supports 
dynamic behaviour modification of agents and which enables ad-hoc conversations 
and dynamic co-operation of agents to enable commerce mediating businesses to be 
supported. The dynamic behaviour modification of agents is achieved by the 

35 installation and execution of Java classes providing agent behaviours on the fly within 
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an agent. However, for each workflow model (equivalently for a conversation policy), 
two centralised agents (a Process Manager and a Worklist Manager) need to be 
instantiated. 

5 The present invention seeks to obviate and/or mitigate the above problems and 
disadvantages known in the art by providing a multi-agent system architecture which 
provides sufficiently flexibility to support an evolving eCommerce environment, and in 
which all the controls and state changes are implemented using role components. 
Advantageously, by using role components, no specialised agents are required to be 
10 instantiated for each new conversation policy/interaction policy. 

A first aspect of the invention seeks to provide a service component arranged in use to 
enable a client agent to interact with a server agent when requesting a service, the 
service component comprising: a plurality of role components arranged in use to 
15 perform a service interaction between the client agent and the server agent, the role 
components being loaded onto the said client and server agents as appropriate for the 
interaction and when loaded, arranged to provide the client and server agents with 
information on the interaction requirement(s) to enable the requested service to be 
provided. 

20 

Preferably, the Initiator role components are provided by a service provider agent to a 
service consumer agent. 

Preferably, the role components are attached with a component description, the 
25 component description including details of the minimum client platform capability of the 
client agent and the interfaces used by the client agent to interact with the role 
component. 

Preferably, the Initiator role component can control its state and can be reused for 
multiple requests. 

30 

Preferably, the role components are distributed by a mediator agent. 

Preferably, the mediator agent provides the role components dynamically to the client 
and server agents. 



35 
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More preferably, the mediator agent identifies a suitable role component using a 
service description and component description of the role component. 

Preferably, one of said plurality of role components is an Initiator role component 
5 provided dynamically to the client agent whilst the client agent is running. 

Preferably, one of said plurality of role components is a Respondent role component 
provided dynamically to the server agent whilst the server agent is running. 

10 A second aspect of the invention relates to a service component arranged to enable a 
client agent to interact with a server agent when requesting a service, the service 
component comprising: a plurality of role components arranged to perform a service 
interaction between the client agent and the server agent, the role components 
providing the client and server agents with information on the interaction requirements 

15 to enable the requested service to be provided, wherein the service component is 
generic to the client and server agents and is dynamically installed into at least one of 
the client and server agents when these agents are already running. 

A third aspect of the invention relates to a multi-agent service architecture having a 
20 service component arranged to enable a client agent to request a service from a 
service agent, the architecture including: a mediator agent arranged to provide a role 
component to the client agent, wherein once the role component is loaded on the client 
agent, the client agent is provided with information which enables the service to be 
provided by the service agent. 

25 

A fourth aspect of the invention relates to a method of providing a user with access on 
demand to a remote service, the method comprising the steps of: generating a client 
agent for the user to request the service from a server agent; providing the client agent 
with at least one service component arranged to modify the client agent to enable the 

30 client agent to interact with the server agent when requesting the service; forwarding 
the modified client agent to the broker to enable the server agent and modified client 
agent to interact; and responding to the client agent's request to provide the requested 
service, wherein the service component provided comprises: a plurality of role 
components arranged to perform service interactions between the client agent and the 

35 server agent, the role components providing the client and server agents with 
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information on the interaction requirements to enable the requested service to be 
provided. 

A fifth aspect of the invention relates to a method of enabling a software agent to 
5 participate in an inter-agent interaction within a MAS architecture, the method 
comprising the steps of: determining at least one of a plurality of role components for 
use by a service component of said software agents required for participation in the 
inter-agent interaction; identifying a mediator agent in the MAS which is capable of 
providing at least one role component required by the software agent for participation in 
10 the inter-agent interaction, the mediator being identified by means of a service 
component description as having a suitable role component for the service component; 
dynamically installing the role component provided by the mediator agent on the 
software agent; and loading the role component on the software agent to enable the 
software agent to participate in the inter-agent interaction. 

15 

A sixth aspect of the invention relates to an agent internal architecture for dynamically 
installing and executing role components, the architecture comprising: 

a Co-ordinator controller, a Load manager, a Component installer, and a 
Package manager. 

20 

A seventh aspect of the invention relates to a method of enabling a software agent to 
manage downloaded role components, the method comprising the steps of: 
determining whether there are any components downloaded already in the local 
component storage; performing version checking for downloaded Initiator role 
25 components if there exist any Initiator role components; locating the Mediator agent 
and downloading any Initiator role components from the Mediator Agent; packaging the 
downloaded Initiator role components into the local component storage; and 
instantiating the downloaded Initiator role components. 

30 An eighth aspect of the invention relates to a computer product comprising a suite of 
one or more computer programs provided on a computer readable data carrier, the one 
or more computer programs being arranged to implement any one of the method 
aspects of the invention. 
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A ninth aspect of the invention relates to a signal conveying a suite of one or more 
computer programs over a communications network, the suite of one or more computer 
programs being arranged when executable to implement any one of the method 
aspects of the invention. 

5 

It will be appreciated by those skilled in the art that the invention can be implemented in 
any appropriate combination of software and hardware, and that invention can also be 
implemented by a synergy of software and hardware, for example, when a computer 
software product comprising one or more computer programs arranged to implement 
10 any one of the method aspects of the invention is run on a computer 

The invention provides a MAS architecture which uses conversational components as 
the main tool for interactions amongst participating agents. This allows an information 
consumer agent to interact with an information provider agent to supply an information 
15 service via an unknown language or interaction protocol, which supports the growing 
needs of service providers to differentiate their services in virtual environments such as 
electronic commerce. 

The architecture of the invention enables agents residing on the same agent platform 
20 to interact using a new language, ontology, or interaction protocol by utilizing an ad-hoc 
interaction protocol which can handle messages with an unknown language and 
ontology. Advantageously, the generic service components enabling ad-hoc 
conversations can be dynamically installed into agents which are already running. 

25 The features of the invention as defined above or by the dependent claims may be 
combined in any appropriate manner with any appropriate aspects of the invention as 
apparent to those skilled in the art. 

The preferred embodiments of the invention will now be described with reference to the 
30 accompanying drawings, which are by way of example only and in which: 

Figure 1 shows the internal architecture of a conversational service component 
according to the invention; 
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Figure 2A shows in more detail the internal structure and operational process of a C- 
COM service component; 

Figure 2B shows in more detail the internal of an Outer Interface of a Initiator Role 
5 component of a C-COM service component; 

Figure 2C shows schematically an alternative representation of the internal structure of 
the Initiator Role component of a C-COM service component; 

10 Figure 3A shows a state transition diagram of an Initiator role component according to 
the invention; 

Figure 3B shows a state transition diagram of a respondent role component according 
to the invention; 

15 

Figure 4 shows generic agent roles in a multi-agent architecture according to the 
invention; 

Figure 5 shows the structure of the co-ordination engine and the process for 
20 downloading, installation, and execution of an Initiator role component according to the 
invention; 

Figure 6 shows the process for loading an instance of a conversational service 
component according to the invention; 

25 

Figure 7 shows an embodiment of the invention where a user is requesting services 
from a server; 

Figure 8A shows an embodiment of the invention in which information service 
30 consumer and provider agents interact via a mediator agent; and 



Figure 8B shows an embodiment of the invention comprising a multi-agent system for 
airline-ticketing. 
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There follows a detailed description of the preferred embodiments of the invention, 
which include a description of the best mode of the invention as currently contemplated 
by the inventors. Even where not explicitly described, it will be apparent to those 
skilled in the art that certain features of the invention can be replaced by their known 
5 equivalents, and the scope of the invention is intended to encompass such equivalents 
where appropriate. 

The multi-agent system architecture of the invention is arranged to enable a plurality of 
software agents to interact, even when one or more of said software agents needs to 

10 employ an initially unknown content language and/or interaction protocol. The 
interaction is facilitated by providing a MAS architecture which supports the provision of 
one or more service components to a software agent which seeks to interact with 
another software agent. The additional service components are required when the 
initiating software agent and/or the responding agent determines that the interaction 

1 5 involves a content language and/or interaction protocol that it does not have the ability 
to support. 

The service components are provided in a plug-and-play form, i.e., a service 
component is provided in any suitable form which the software agent is able to readily 

20 incorporate and then use directly, and which can be incorporated by the software agent 
dynamically without having to abort its interaction with other software agent (i.e., whilst 
the interaction proceeding, the additional software service components can be added 
to enhance one or more of the interacting software agents on the fly). The plug and 
play service component of the invention are termed herein "conversational 

25 components" (C-COMs). 

Once a C-COM has been successfully installed, the two generic roles it supports 
(Initiator and Responder) are incorporated into the respective software agents, and 
provide both the initiating and responding agents with the same level of understanding 

30 of the ontology used within the messages they exchange during their interaction with 
each other. Thus, the conversational components (C-COMs) comprise software 
components which enable at least the required agent interactions (i.e., request and 
response) to occur during an information trade. Whilst the C-COM consists of at least 
the two generic roles, more role components (according to the roles needed for the 

35 interactions) may be provided to enable all interaction related messages to be 
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composed and interpreted as appropriate by the role components which the various 
interacting agents support. 

Thus within the multi-agent system (MAS) architecture according to the invention, plug- 
5 and-play of service components (C-COMs) into software agents to facilitate inter-agent 
interactions provides a "conversational" facilitator for inter-agent interaction. The C- 
COM software is arranged to enable required agent interactions (i.e. a request and 
response) to occur for a given service when the C-COM software is loaded 
appropriately onto the agents participating in the interaction. 

10 

Accordingly, a service component (C-COM) for plug and play in a software agent in a 
multi-agent system (MAS) can be defined as a software component which is used as 
the principle means of interaction between software agents and which can in preferred 
embodiments of the invention be installed and executed by a software agent 

15 dynamically. Generally, a C-COM service component will comprise an implementation 
of an interaction pattern which is a template of a frequently used interaction scenario 
amongst roles. For example, the interaction pattern for an auction can be described 
as follows. Firstly, the seller advertises something to sell; secondly, the one or more 
buyers send their bids to the seller; finally, the seller sells the product to a buyer who 

20 has sent the best bid before the closure of the auction. The C-COM service 
component is thus formed as a re-usable software component based on this interaction 
pattern. The C-COM service component can be generated in any suitable form which 
can be dynamically installed on and executed by one or more software agents within 
the MAS. A conversational component (C-COM) can therefore also be defined to be 

25 an implementation of a reusable interaction pattern which produces a service via 
interactions among role components within the conversational component. 

The C-COM service component thus structurally comprises a plurality of role 
components for the interaction (where the number of role components provided is 
30 determined by the number of roles needed for the interactions). All the service 
interactions are performed via messages which can be interpreted and composed by 
the role components. As the role components are aware of the content language, 
ontology, and interaction protocol used for a given service, an agent can participate (as 
a client, a server or both) just by installing one or more C-COM service components for 
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a given service, even if the agent has no awareness of the required content language 
or interaction protocol. 

The two generic role components provided by a C-COM service agent are the Initiator 
5 and Responder role components. The Initiator and Responder role components are 
aware of the content language, ontology, and IP used for any given information trade. 
From an agent's point of view, the Initiator role component is a black box which hides 
the interaction process with its designed Respondent role components from its master 
agent (the agent which installs the role component) and only exposes an interface 
10 which specifies the input and output data needed to execute the role component. It is 
possible for more than one role component to be plugged into an agent concurrently. 

The C-COM service components are provided by a mediation facility which enables 
each software agent to determine an appropriate C-COM service component and/or to 

15 identify the appropriate role component provided by a C-COM service component to 
enable the software agent to proceed with a specific inter-agent interaction. In an 
Information MAS-type environment, the invention enables software agents such as an 
information provider agent (IPA) to participate in an existing agent society by providing 
the Information Provider Agent (IPA) with one or more appropriate Initiator role 

20 component(s) to enable interaction with one or more information consumer agents 
(ICAs) via a public mediator facility. An information consumer agent (ICA) is able to 
interact with the new information provider agent (IPA) by installing the Initiator role 
component for a given information trade, even if the Information Provider Agent (IPA) 
doesn't initially recognise the required content language or interaction protocol required 

25 for the information trade. It is the multi-agent system architecture (CCoMaa) which 
defines the roles of the participating agents and the procedures which they should 
comply with in order to install C-COMs and to be capable of interacting with the 
corresponding agents during the information trade. 

30 The two generic roles for the C-COMs are Initiator 1 and •Respondent', however, these 
roles can be specialised into more roles according to the application requirements. The 
Initiator' role component is installed in a client agent and is required to obtain the 
service result from a server agent. The 'Respondent' role component is installed in a 
server agent in order to provide services to the client agent and to one or more other 

35 client agents. The client agent and server agent interact via the messages which are 
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generated and interpreted by their respective role components according to a pre- 
defined content language, ontology, and interaction protocol for the service in question, 
which are defined by the multi-agent system architecture (CCoMaa). 

5 One embodiment of the invention provides a mediator agent for a multi-agent 
architecture (MAS) which provides the role components to the software agents 
dynamically, i.e., on the fly. For example, a mediator agent may provide an 'Initiator' 
role component to a client agent dynamically whilst the client agent is already running 
in the MAS. As a result, the client agent does not need the 'Initiator 1 role component a 
10 priori, instead, the client agent can request a service and receive it without prior 
knowledge of the content language or interaction protocol required by the server agent 
providing the requested service. 

The appropriate mediator agent for a software agent in a MAS is identified by 
15 determining whether the mediator agent has a suitable Initiator role component for the 
software agent's desired inter-agent interaction. This is achieved through the use of a 
service component description of the service component which provides a description 
of each of the plurality of role components comprising the service component, including 
the necessary Initiator and Respondent role components. The mediator agent then 
20 provides the role components dynamically and these are loaded on the software agent 
whilst the agent is running in the MAS. Once an Initiator role component is loaded from 
a mediator agent, the client agent is directly able to request a service from the available 
service agent. Suitable server agents are identified by the downloaded Initiator role 
component when the client agent executes it to get a service result. Advantageously, 
25 the resulting MAS has a very loosely coupled architecture which allows agents to join, 
disengage and/or rejoin with minimal impact, just by installing one or more C-COMs. 

Referring now to Figure 1, the structure of a service component (C-COM) for a 
software agent according to a first embodiment of the invention is shown schematically. 
30 In Figure 1, C-COM 1 comprises four role components 2,3,4,5 . Each role component 
2, 3, 4, 5 can be plugged dynamically into an agent. Four agents are shown 
schematically in Figure 1, as agents 6, 7, 8, 9. 

From an agent's point of view, each role component is a black box which hides the 
35 interaction protocol 10 with other role components and just shows an interface which 
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specifies the input and output data needed to execute the role component. As shown in 
Figure 1, a role component 2,3,4,5 is plugged into an agent 6,7,8,9 respectively when 
that agent 6,7,8,9 participates in an interaction. However, more than one role 
component can be plugged into an agent. An agent which installs a role component is 
5 called a Master Agent of the role component. 

The interactions between role components of the C-COM are controlled by an 
Interaction Protocol (IP). Each role component performs actions in each stage of the 
Interaction Protocol to produce the required service. A role component is defined as a 
finite-state-machine that performs actions according to its current state to produce the 
10 required service. A role component reveals a set of interfaces to its user. The structure 
of a role component is discussed in more detail later with reference to Figures 2A and 
2B of the accompanying drawings. 

Accordingly, the C-COM can be denoted as follows: 
15 C-COM = <IP, Cs> 

where IP is an Interaction Protocol, as defined below, and Cs is a set of finite state 
machine-like components having one or more roles defined in the IP. The term 
Interaction Protocol (IP) describes what sequences of which messages are permissible 
20 among a given set of roles, for example, see the specifications of standard interaction 
protocols (by FIPA)from http://www.fipa.org/repository/ips.html. 

In Figure 2A, each role component 21, 22 comprises an Interaction Protocol Scheduler 
(IPS) 23, 24, a Message Handler (MH) 25, 26, an Action Pool (AP) 27, 28 and one or 

25 more Interfaces 29, 30, 31. Each role component 21, 22 functions as a Finite State 
Machine, driven by internal state changes, and has a different set of internal states 
according to the role the component plays in the interaction protocol employed for a 
given C-COM service component. Each Interaction Protocol Scheduler (IPS) 23, 24 
schedules and executes all the actions stored in the Action Pool (AP) 27, 28 of its role 

30 component 21 , 22 according to the internal state changes of its role component. 

For this purpose, each role component 21, 22 maintains an Interaction State which is 
managed by the Interaction State Manager (ISM) 32, 33. The Message Handler (MH) 
25, 26 of each agent's role component is responsible for validating outgoing messages 
35 and interpreting incoming messages forming the interaction between the two agents. 
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The role component 21, 22 provides a number of interfaces 29, 30, 31 for 
customisation purposes. In this context, an interface 29, 30 31 is defined as a set of 
method signatures. An interface 29, 30, 31 must be provided with an implementation 
of the method signatures to be executed at run time. 

5 

As shown in Figure 2A (and also in Figure 2B) Initiator role component 21 has two 
kinds of interface: an Outer Interface (Ol) 29 and an Inner Interface (II ) 30. The Outer 
Interface (Ol) 29 defines the signature of a trigger method. The trigger method 
signature triggers the execution of the entire C-COM; i.e., it triggers the input data and 
10 the service result which is returned to the master agent (not shown in Figure 2C) which 
installs the role component Calling the trigger method in the Outer Interface (Ol) 29 
activates the Initiator role component 21 which then activates all its other Respondent 
role components (e.g., in Figure 2C it activates respondent role component 22) in the 
appropriate order. 

15 . 

An Inner interface 30 defines a trigger method (in that a call to the method by a service 
consumer activates the function of the whole C-COM) which is called by a service 
consumer to get a service result from the role component 2. The role component 2 
implements the inner interface 30 to produce the required service result. Figure 2B 
20 shows more detail of an Inner interface 30, together with some of the other elements 
comprising the role component which are described in more detail in the description of 
Figures 2A. (and 2C) The inner interface 30 defines four methods that can be called by 
a device that installs the Initiator Role component: 

25 startConversation(Object Arg) method triggers the initiation of a coordination 

process; 

getConversationPolicyO method returns the business rules used in the 
coordination; 

30 

getConversationState() method returns the current state of the coordination; and. 

cancelConversationQ method is used to abort a coordination in the middle of 
the coordination. 

35 
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An Internal Interface (II) 30 is an information channel from the master agent to the role 
component 21. A role component is able to ask its master agent to provide ontology 
items that are necessary to create a message. For example, if a Respondent agent 
needs access to a knowledge source to get information to populate a response 
5 message, it can request that a master agent provides the Respondent role component 
with the requested information. The same is necessary for an Initiator role component. 

Outer interface 29 defines methods which are called by the role component 2 to get 
application specific input The agent which installs the role component 2 should provide 

10 an implementation of the outer interface 29. Then, the role component 2 interacts with 
the implementation to produce the required service result. The outer interface 29 
enables the customisation of the role component 2 for different application 
requirements. For instance, a Respondent role component can be reused in different 
applications by providing different implementation of outer interface 29. The 

15 communication between the role component and application specific implementation 
via outer interface is controlled via Coordination Controller 51 in Figure 5. More 
specifically, all the request for application specific input value is to through the outer 
interface 30 to the Coordination Controller 51 which is then responsible for getting the 
required value from a human user defined implementation or by executing another C- 

20 COM. 

The operational process of a C-COM can also be understood with reference to Figure 
2A. The activation of a C-COM is started when the startConversation() method of a 
Initiator Role component is called (101) by Initiator Role Component 21. The method 

25 call (101) triggers the change of Interaction State (102) which is propagated to activate 
the Interaction Protocol Scheduler (IPS) 23 of the Initiator Role Component 21. The 
IPS 23 then schedules the next action that should be executed from the Action Pool 27. 
The execution of an action will return a message (103) that should be sent to 
Respondent Role component (22). The IPS 23 sends the message (104) to the 

30 'Message Handler' module 25 to send it to appropriate Respondent Role components 
(e.g. Respondent Rote Component 22 as shown in Figure 2A). The 'Msg Handler' 
module 25 will find any devices that have installed the Respondent Role component 
(22) of the C-COM by querying a yellow page service (provided within the MAS, see 
the FIPA abstract architecture specification for further details) and the Message 

35 Handler 25 sends the message (A) to one or more found Respondent Role 
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components (22). The 'Message Handler 1 module 26 of a Respondent Role component 
22 forward the received message (A) to its 'Interaction State Manager* module (33) to 
update the state (106). This triggers the work of the IPS 24 of the Respondent Role 
component 22 which schedules actions that should be executed to handle the input 
5 message (107 & 108). The activated action may call any methods (109) from the Outer 
Interface (31) of the Respondent Role component 22 to get further input data required 
(e.g. from a human user or any other information source - not shown in Figure 2A). 
Once the action pool (AP) has prepared a response message (110) , it forwards the 
message to the IPS (24) which passes the message to the 'Message Handler' 

10 module (26) to send the message (B) back to the Initiator Role component (21) (111). 
The 'Message Handler' module 25 of the Initiator Role component 21 then forwards the 
received response message (B) from the Respondent Role component 22 to the 
'Interaction State Manager' module (32) to update the state of the coordination (113). 
This, again, triggers the work of the IPS 23 to schedule the next action(s) (updating 

15 again state 102) that should be executed by the initiator role component 21 according 
to one or more pre defined business rules (which are provided by calling the 
getConversationPolicyQ method which returns the business rules used in the 
coordination). 

20 Figure 2C shows alternative simplistic schematic representations of the internal 
structure and state transitions of a role component. In Figure 2C, each role component 
comprises four main modules: a Protocol Manager (equivalently an Interaction Protocol 
Scheduler) 11, an Interface (usually either an Inner interface 12a or an outer interface 
12b although both are shown in Fig. 2), an Action pool 13, and Message Handler 14. 

25 The Protocol Manager 1 1 controls all the actions of a role component according to the 
interaction protocol employed by the role component and the nature of the role 
component in the interaction protocol (see Figure 1). The Protocol Manager 11 
interacts with the Message Handler 14 to send and receive messages. The Message 
Handler 14 filters messages which are sent to the role component from the message 

30 queue of its Master Agent. 

In the context of the invention, both the inner interface 12a and the outer interface 12b 
are defined as a set of method signatures that specify the method name, input 
arguments, and output of the method (c.f. the definition of 'Interface' in Java). When a 
35 role component interacts with its Master Agent, the Master Agent installs the 
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implementation of the appropriate interface 12a or 12b, in accordance with the role of 
the role component. 

Inner interface 12a defines a trigger method (in that a call to the method by a service 
consumer activates the function of the whole C-COM) which is called by a service 
consumer to get a service result from the role component 2. The role component 2 
implements the inner interface 11a to produce the required service result. Outer 
interface 12b defines methods which are called by the role component 2 to get 
application specific input. The agent which installs the role component 2 should provide 
an implementation of the outer interface 12b. Then, the role component 2 interacts with 
the implementation to produce the required service result. The outer interface 12b 
enables the customisation of the role component 2 for different application 
requirements. For instance, a Respondent role component can be reused in different 
applications by providing different implementation of outer interface 12b. The 
communication between the role component and application specific implementation 
via outer interface is controlled via a Coordination Controller 71 (see Figure 5). More 
specifically, all the request for application specific input value is to through the outer 
interface 12b to the Coordination Controller 71 which is then responsible for getting the 
required value from a human user defined implementation or by executing another 
CCOM. 

Thus an Initiator role component is a role component which has an inner interface 12a 
and an outer interface 12b, whereas a Respondent role component is a role 
component which has an outer interface 12b, but not an inner interface 12a. When a 
role component is installed into a Master Agent, the component has "Ready" state. 
When any methods in Inner Interface/Outer Interface or Actions are executed by 
Protocol Manager 11, the component transitions to next the state ("State 2", "State 3", 
and so forth until finally the "Completed" state is achieved). Once the component 
reaches to "Completed" state, it automatically resets its state to "Ready" waiting 
another request from a service consumer (for the Initiator role component) or the 
Initiator role component (for the Respondent role component). 

The Initiator and Respondent role components are generic in that they can be 
specialised for more specific role components according to the requirements of the 
target C-COM. A Master Agent can handle multiple trigger messages concurrently by 
installing multiple Respondent role components. 



WO 2004/084068 



20 



PCT/GB2004/001168 



Figures 3A and 3B show the state transition diagrams which show the interna! 
functionality of the Initiator and Respondent role components respectively. 

In Figure 3A, an installed Initiator role component is initially in an "Idle" state 40. After 
5 a service request has been issued by the Initiator role component the Initiator role 
component is in the "Schedule Next Behaviour" state 41. The behaviour execution 
request then causes the Initiator role component to execute the behaviour (state 42) 
and once this is finished the component returns to its schedule next behaviour state 41. 
When a new interaction is required the Initiator role component prepares a request 

1 0 message 43. Once the request message has been sent by the Initiator role component 
to one or more Respondent role components, the Initiator role component is then in a 
wait response message state 44. Once the response message has been received, the 
Initiator role component is in a handle response message state 45. The response 
message is then interpreted by the Initiator Role component which then enters its 

15 "Schedule Next Behaviour" state 41, before delivering the service result to the caller of 
its Inner Interface and returning to the idle state 40. 

In Figure 3B, an installed Respondent role component is initially in the "Idle" state 46. 
After a service request has been issued by the Respondent role component, the 

20 Respondent role component is in the "Schedule Next Behaviour" state 47. The 
behaviour execution request then causes the Respondent role component to execute 
the behaviour (state 48) and once this is finished the Respondent role component 
returns to the "Schedule Next Behaviour state 47. When a new interaction is required 
the Respondent role component enters the "Activate Agent Interface" state 49. Once 

25 the response is received from an agent, the Respondent role component again returns 
to the "Schedule Next Behaviour state 47. The response message is then prepared 
and the Respondent role component agent enters the "Send Response Message" state 
50. Once the message has been sent, the respondent role component agent returns to 
the "Schedule Next Behaviour" state 47 before returning to "Idle" state 46. 

30 

Thus, the multi-agent system (MAS) architecture (CCoMaa) according to the invention 
enables a plurality of software agents to interact with each other by installing 
appropriate C-COM service component role components. The C-COM service 
components allow existing agents to interact with new service-providing agents (SPAs) 
35 by dynamically installing and executing Initiator role components which are provided by 
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the new service providing agents. To facilitate this dynamic configuration change 
management, the multi-agent system architecture (CcoMaa) needs certain special 
agents having predefined roles. For example, special agents can be implemented by 
the multi-agent system architecture (CcoMaa) to provide the functions of a service 
5 mediator, a service consumer, and a service provider with the multi-agent system 
architecture (CCoMaa). Fig. 4 shows schematically some generic agent roles in the 
multi-agent system architecture (CcoMaa) and their interactions. 

In the multi-agent system (MAS) architecture according to the invention, an agent may 
10 have one of a plurality of roles. For example, as Fig. 4 shows schematically, the agent 
may be a service provider agent (SPA) 61, a service mediator agent (SMA) 62, and a 
service consumer agent (SCA) 63. It will be appreciated by those skilled in the art that 
the term "SPA" can be considered in this embodiment of the invention as comprising a 
"server agent" and that the term "SCA" can be considered in this embodiment of the 
15 invention as comprising a "client agent" where the Multi-Agent System Architecture 
(CCoMaa) provides a client-server implementation of the invention. Thus, an 
information provider agent (IPA) is an example of a Service Provider Agent (SPA), and 
a Information Consumer Agent (ICA) is an example of an Service Consumer Agent 
(SCA). 

20 

The Service Provider Agent (SPA) 61 registers the service description, component 
descriptions, and executable Initiator role components (actions "A" shown in Fig. 4). 
The Service Provider Agent (SPA) 61 registers its service description to the service 
mediator agent 42 by a process which differs from the one defined by FIPA. 

25 

More specifically, according to the invention, the Service Provider Agent (SPA) 61 
registers an executable Initiator role component, a component description (which is 
used by the Service Consumer Agent (SCA) for installation and execution of the 
executable Initiator role component), and a service description. Advantageously, as 
30 the Initiator role component generates and interprets all messages which will be 
exchanged by the Service Provider Agent (SPA) 61 with a Service Consumer Agent 
(SCA) 63, there is no need for a Service Consumer Agent (SCA) 63 to have knowledge 
a priori to requesting a service of the requirements imposed by the Service Provider 
Agent (SPA) 61. 
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The Service Mediator Agent (SMA) 62 according to the invention is responsible for 
maintaining the service registry and Initiator library that contains Initiator role 
components (actions "B" in Fig. 4). The service registry plays the role as defined in 
FIPA specifications or other similar systems. The Initiator library maintains the pair of 
component description and the executable Initiator role component. The component 
description specifies the information needed to install and execute the executable 
Initiator role component. 

The difference between the service registration process in this invention and that of 
FIPA can be explained in detail as follows in which a specific embodiment of the 
invention relating to an airline ticketing scenario is described. This embodiment is 
described in more detail later with reference to Figure 8 of the accompanying drawings. 

FIPA service registration 

Firstly, in the FIPA specifications, a FIPA Service Provider Agent (SPA) registers its 
description to a Directory Facilitator (DF) agent as per the following example which is 
described in terms of pseudocode: 

<DFAgentDescription> 
<Name> 

<Agent-ldentifier name="routeplanner@f oo.com ". 
address="iiop://foo.com/acc" /> 
</Name> 

<Protocol name= n AdHoc-Protocol" /> 
<Ontology name=Traver /> 
<Language name=TIPA-SLO" /> 
<Language name="KIF" /> 
<ServiceDescription> 

<Name> bookFlight </Name> 

<Type> BookingService </Type> 

<Ontology> Travel </Ontology> 

<Protocol> FIPA-Request </Protocol> 

<Property name=domain, value=international /> 
</ServiceDescription> 
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</DFAgentDescription> 

The DF agent stores the agent description in its local table. When a Service Consumer 
Agent (SCA) sends a request message to the DF agent to locate a Service Provider 
Agent (SPA) for a given service, the DF agent returns the names of any suitable SPAs 
it finds to the SCA. Once the Service Consumer Agent (SCA) receives the name of 
one or more SPAs, it starts an interaction with those SPAs employing the ontology, 
language, and interaction protocol specified in the service description. 

The format of the query message that the Service Consumer Agent (SCA) sends to the 
DF agent is as follows in pseudocode: 

(request 

:sender (agent-identifier :name SCA@foo.com :address iiop://foo.com/acc) 
:receiver (agent-identifier :name Mediator@foo.com :address 
iiop://foo.com/md) 

language FIPA-SLO 
: protocol FIPA-Request 
:ontology CCOM-Management 
.content 

(action (agent-identifier :name Mediator@foo.com :address 
iiop://foo.com/md) 

(search 

(ccom-agent-description 
:ontology (set Travel) 
language (set FIPA-SLO KIF) 
: services (set 

(service-description 

:name bookFlight 

:type BookingService 

: ontology Travel 

language SLO 

:protocol FIPA-Request 

: properties (set 
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(property :name domain :value 



international)))))))) 

According to the invention, however, the above message is used only by a Mediator 
5 Agent to find appropriate SPAs and returns the list of names of suitable SPAs (with 
each entry in the form of "<Agent-ldentifier name="routeplanner@foo.com w . 
address="iiop://foo.com/acc" /> ") to the SCA. 

Service Registration using Role Components 



On the other hand, the Service Provider Agent (SPA) of the invention registers the 
following form of description to a sen/ice mediator agent (SMA) . The example is 
provided in pseudo code and comprises of a sample CCoMaa agent description which 
is used to register a service and Initiator component by a Service Provider Agent (SPA) 
15 comprising an Information Provider Agent (IPA) (see also the description referring to in 
Figures 8A and 8B which relate to an embodiment of the invention concerning airline 
ticketing information): 

<CCOMAgentDescription> 
20 <Name> 



10 



<Agent-ldentifier 
address="iiop://foo.com/acc" /> 
</Name> 



name="dummv@foo.com ". 



<Protocol name= n AdHoc-Protocol n /> 



25 



<Ontology name= n Travel" /> 
<Language name="FIPA-SL0" /> 
<Language name="KIF" /> 



30 



<ServiceDescription> 

<Name> bookFlight </Name> 

<Type> BookingService </T ype> 

<Ontology> Travel </Ontology> 

<Property name=domain, value=international/> 



</ServiceDescription> 



35 



<ComponentDescription> 

<package name-'com.travelagent.booking" 
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mainclass="FlightJnitiation. class" /> 
<MinJVM> JDK1.1.X </MinJVM> 
<lnnerlnterface> 

<Method name=getTicket> 

<lnput order=1, name= ,, Route", 

type=Travel. Booking. Route /> 

<Output type=Travel.Booking.TicketList /> 
</Method> 
</lnnerlnterface> 
</ComponentDescription> 
</CCOMAgentDescription> 

The Multi-Agent System Architecture (CCoMaa) agent description thus consists of a 
service description and a component description. The service description consists of 
15 name, type, and properties fields. The component description has three sub- 
descriptions: Interface, file and graphical user interface (GUI) descriptions. 

The Interface description specifies the trigger method and ontology items used as input 
and output of the trigger method. The File description is used by the ICA to install the 
20 downloaded Initiator component in the local device on which the agent is running. 
Finally, the GUI description is optional. A Service Provider Agent (SPA) 61 can provide 
a Service Consumer Agent (SCA) 63 with a GUI component which can be used to 
retrieve additional ontology items (which might not be known to the SCAs) used by the 
Initiator role component to pass to the Respondent role component. 

25 

Advantageously, once the service provider has registered its service(s) to an Service 
Mediator Agent (SMA) 62, any Service Consumer Agent (SCA) 63 can contact the 
Service Mediator Agent (SMA) 62 to get contact information for the Service Provider 
Agent (SPA) 61 . To get the contact information, the Service Consumer Agent (SCA) 63 

30 sends a message that contains a service description to the Service Mediator Agent 
(SMA) 62 (action "C" in Fig. 4). The contents of the message can be as per the 
following pseudocode example (again given in the context of the Service Consumer 
Agent (SCA) comprising an ICA, and the Service Provider Agent (SPA) comprising an 
IPA, see Figures 8A and 8B for more details). 

35 (request 



5 
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:sender (agent-identifier :name SCA@foo.com :address iiop://foo.com/acc) 
:receiver (agent-identifier :name Mediator@foo.com :address 
iiop://foo.com/md) 

:ontology CCOM-Management 
5 language SLO 

iprotocol FIPA-Request 
xontent 

(action (agent-identifier :name Med iator@f oo. com :address 

iiop://foo.com/md) 
1 0 (search 

(ccom-agent-description 

:services (set ; 
(service-description 
:name bookFlight 
1 5 :type BookingService 

: properties (set 

(property :name domain :value 

international)))) 

: component (set 

20 (component-description 

:min-jvm jdk1.2.x 

:inner-interface (set (method :input 

Travel. Booking. Route)))))) 



25 This request message is also different from that of FIPA, as the service component 
agent (SCA) doesn't have to specify a language and protocol in a service description 
used for service acquisition. Once a Service Consumer Agent (SMA) 63 sends this 
request message to a Service Mediator Agent (SMA) 62, the Service Mediator Agent 
(SMA) 62 will search through its list of pre-registered Service Provider Agents (SPA) 

30 61. 



If a matching agent description is found, the Service Mediator Agent (SMA) 62 returns 
the agent description of the Service Provider Agent (SPA) 61 and an executable 
Initiator role component to the Service Consumer Agent (SCA) 63 (actions "D" in Figure 
35 4). If any contact information is returned by the Service Mediator Agent (SMA) 62, the 
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Service Consumer Agent (SPA) 61 installs the executable Initiator role component into 
its Initiator library, based on the component description (action "E" in Figure 4) and 
executes the Initiator role component to get the service result from the Service Provider 
Agent (SPA) 61 (actions "F" and U G" in Figure 4). 

5 

Dynamic download, installation and execution of C-COM 

The Service Consumer Agent (SCA) 63 shown in Fig. 4 is equipped with a co- 
ordination engine which is responsible for downloading, installing, and executing an 

10 Initiator role component. Referring now to Figure 5, the structure of the co-ordination 
engine and the process for downloading, installation, and execution of an Initiator role 
component is shown schematically. The co-ordination engine forms part of an agent 
internal architecture arranged to enable the dynamic installation and execution of role 
components. The agent internal architecture comprises: a Co-ordinator controller, a 

15 Load manager, a Component installer; and a Package manager. 

In Figure 5, co-ordination controller 71 activates a load manager module 72 when an 
executable Initiator role component instance is requested to perform a required service 
by another component from the Service Consumer Agent (SCA) 63 (see Fig. 4). If the 

20 Initiator role component has already been downloaded before, the load manager 72 
module may (depending upon the requirements of the application) perform a version 
check to ensure that the latest version is installed. The versioning process is 
determined by the version control scheme currently in place. Otherwise the load 
manager 72 module will instantiate the Initiator role component and pass the 

25 instantiated object back to the co-ordination controller 71 where it will be executed. If 
there is no locally installed copy of the Initiator role component the load manager 
module 72 forwards a request to the component installer module 73, which will attempt 
to locate a Service Mediator Agent (SMA) 62 (see Fig. 4) that contains the required 
Initiator role component. 

30 

There are a variety of mechanisms that can be used to discover the available Service 
Mediator Agents (SMA) 62 within the network. For example, if the application is running 
on a FIPA compliant agent platform, the Directory Facilitator (DF) can be used. When 
the component installer module 73 locates a C-COM that matches the given 
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requirements through querying a Service Mediator Agent (SMA) 62, the component 
installer 73 will download the Initiator role component of the C-COM. 

The component installer 73 then returns the results of its search to the load manager 
5 72. If a suitable C-COM was located, the result will contain the Initiator portion of the 
Initiator role component. The load manager 72 then stores the Initiator role component 
within the C-COM library 75, and requests that the package manager 74 installs the 
Initiator role component so that it can be executed. The package manager 74 then 
registers the Initiator role component within the C-COM library 75, and returns control 
10 to the load manager 72 . Once the Initiator has been downloaded and installed, the 
load manager 72 records the details of the process so that in future the Initiator role 
component does not need to be downloaded again unless a new version becomes 
available. The result of the interaction with the Service Provider Agent (SPA) 61 is 
returned to the requester of the service result. 

15 

Fig. 6 shows steps in a method for loading an instance of a C-COM by the 
collaboration of Load Manager 72, Component Installer 73, and Package Manager 74 
in Figure 5. First, Load Manager 72 asks Package Manager 74 if there are any Initiator- 
role components available for a service request. If there exists a Initiator-role 

20 component (step 81) that fulfils the required service, the Load Manager 72 then 
performs a version check (step 83) by sending a command to the Component Installer 
73. The Component Installer 73 then contacts the Service Mediator Agent (SMA) 62 
(see Figure 4) to get the latest version number for the corresponding Initiator role 
components. If the local Initiator role component is the latest version, the Load 

25 Manager 72 instantiates the role component and returns the instance to the 
Coordination Controller 71 and finishes the process (step 89). 

If there is no role component managed by the Package Manager 74, the Load Manager 
72 asks the Component Installer 73 to download one or more Initiator role components. 

30 Then the Component Installer 73, first, locates a Service Mediator Agent (SMA) (step 
82). If no Service Mediator Agent (SMA) 62 is found (step 85), the process is finished. 
Otherwise, the Component Installer 73 queries the found Service Mediator Agent 
(SMA) 62 to get any appropriate Initiator role components (step 84). If found, the 
Component Installer 73 downloads the found Initiator role components (step 86) and 

35 passes them to the Package Manager 74 to store in its local component store for later 
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use (step 88), and finally instantiates the Initiator role component (step 87) and finishes 
the process (step 89). 

An embodiment of the invention can be used to implement a dynamic version 
5 management system in which service providers can upgrade services without affecting 
their customers by providing upgraded Initiator role components to a Service Mediator 
Agent (SMA) 62. The Service Consumer Agent (SCA) 63 needs to only compare 
versions of the local Initiator and remote Initiator when it contacts a Service Mediator 
Agent (SMA) 62. The version upgrade is then done automatically before the actual 
10 interaction with the Service Provider Agent (SPA) 62 is performed by the Service 
Consumer Agent (SCA) 63, in a manner which is hidden from human users. This 
enables the upgrade to be performed in a seemingly transparent manner for the user's 
application. 

15 Thus the invention enables a user to have improved access on-demand to the latest 
version of an application provided by a remote service over a data/tele- 
communications network. For example, referring now to Fig. 7 of the accompanying 
drawings, a schematic diagram is provided which indicates how a first user 90 can be 
provided with access on-demand to remote services provided by service provider 91 

20 via a brokerage 92. The application used by user 90 provides a client agent which 
interfaces with an Initiator role component 93 provided by a suitable mediator agent 
provided by the brokerage 92. 

In Figure 7, Initiator role component 93 interacts with a Respondent role component 94 
25 set up by the mediator agent, and is able to interface with a Service Provider Agent 
(SPA) of the service provider 91. The Initiator and respondent roles form part of a C- 
COM arranged to facilitate the software agents' interaction with each other in the 
manner described hereinabove with reference to the other embodiments of the 
invention. 

30 

The first user 90 is able to access the latest version of the service they have requested 
from the service provider without having any previous requirement to install any 
components specific to that version, as any required conversational components (i.e. 
Initiator and responder) will be installed as appropriate dynamically into the brokerage 
35 agent. Moreover, once the client agent of a second user 95 is provided with access to 
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an appropriate Initiator role component 96, the client agent is able to interact directly 
with Respondent role component 94 as this is already associated with that type of 
Initiator role component. 

5 In this way, the service provider and user agents can interact regardless of previous 
awareness of the interaction protocol or language required by the particular version of 
the application which the user wishes to access. 

Advantageously, another embodiment of the invention can be used to implement a web 
10 service portal where new web service providers can be registered without affecting 
other existing agents. 

Figure 8A shows an embodiment of the invention in which an information trade occurs 
between a client agent and a service provider agent in a multi-agent system 
15 architecture (CCoMaa) according to the invention. In Figure 8A, the three generic 
agent roles are the Information Consumer, the Information Provider, and the 
Information Mediator. In the CCoMaa shown in Figure 8A, an Information Mediator 
Agent (IMA) mediates all interaction between an Information Provider Agent (IPA) and 
an Information Consumer Agent (ICA). 

20 

As shown in Figure 8A, an Information Provider Agent (IPA) first registers its service 
and component description to an Information Mediator Agent (IMA) (step A). The 
Information Provider Agent (IPA) registers a service description (as required by FIFA) 
and additionally an executable Initiator component and a component description, which 
25 is used by the ICA during the installation and execution of the executable Initiator role 
component. 

The Information Mediator Agent (IMA) is responsible for maintaining the service 
registry and Initiator library that contains Initiator role components (B). The service 
30 registry maintains all the registered service descriptions as defined in FIPA 
specifications. The Initiator library maintains the pair of role component description and 
the executable Initiator role component. The role component description specifies the 
minimum execution environment needed to install and execute the Initiator role 
component. This includes the required runtime environment (e.g. a JVM supporting the 
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CLDC specification) and required computing resources (e.g. 20k storage space, 
160x160 screen resolution, etc). 

Once the Information Provider Agent (IPA) has registered its service(s), any 
5 Information Consumer Agents (ICAs) can contact the Information Mediator Agent (IMA) 
to retrieve the contact information on any registered IPAs. To retrieve the contact 
information, an ICA needs to send a query message containing a service description 
(C). The Information Mediator Agent (IMA) then tries to match the service description 
with one provided by an IPA. If a matching service description is found, the Information 

10 Mediator Agent (IMA) returns a tuple containing a component description of the 
Information Provider Agent (IPA) and an executable Initiator component to the ICA (D). 
If any contact information is returned by the IMA, the ICA installs the executable 
Initiator component into its Initiator library, based on the component description (E) and 
executes the Initiator component to get the service result from the Information Provider 

15 Agent (IPA) (F), (G). 

Figure 8B shows schematically a simplified embodiment of the invention based on an 
airline-ticketing scenario. This scenario is based on a ticket consumer agent (TCA) 
which is assisting its owner in the purchase of an airfare from one of two available 
20 ticket provider agents (TPA). 

In the embodiment shown in Figure 8B, each ticket provider agent (TPA) represents a 
different airline carrier and although they both adhere to the 'official' airline booking 
specification, they also utilize different Interaction Protocols (and so require different 

25 conversation policies to be implemented) as a way of enhancing and differentiating 
their services from competitors. Ticket provider agent TPA (A) provides an additional 
airport transfer service that allows users to book a variety of transport modes to and 
from the airport. In contrast ticket provider agent TPA (B) provides two additional 
services: 1) seat booking, which allows users to book their preferred seating position, 

30 and 2) food selection, which allows a user to choose their preferred meal from a 
selection of available meals. 

Within this example the following assumptions are made: 
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1) The ticket consumer agent (TCA) has on previous occasions interacted with 
ticket provider agent TPA (A) and as such already has an installed copy of the 
appropriate C-COM service component role component(s); 

2) The ticket consumer agent (TCA) contains an implementation of a graphical 
user interface (GUI) which can be used to extract information from the user 
regarding the type of airfare they wish to purchase. This GUI captures the 
values defined within the official airline booking specification. Values such as 
origin, destination, airfare type and price are captured. 



Referring to the scenario shown in the upper part of Figure 8B, firstly, the ticket 
consumer agent (TCA) enables the user to specify via the TCA GUI which type of 
airfare they would like to purchase. Once this information is obtained the ticket 
consumer agent (TCA) requests a Travel. Booking.Ticket' object from the local co- 
15 ordination engine, which responds by loading and executing the Initiator role 
component from ticket provider agent TPA (A). A three-phase interaction protocol (IP) 
is used during the execution of this Initiator role component: 



Phase one: The Initiator role component takes the input provided within its trigger 
20 method and sends a request message (1) to the corresponding Respondent role 
component of ticket provider agent TPA (A). If any available airfares match the 
provided input they are included within the response message (2) sent back to the 
Initiator role component. 



25 Phase two: The Initiator role component's GUI will then show the list of matched 
airfares. Once the user selects an airfare, a request message (3) is sent back to the 
Respondent role component indicating which airfare the user wishes to book. The 
Respondent role component does not process the booking itself, rather it uses the 
services of a finance provider agent (FPA). The Respondent role component asks its 

30 local co-ordination engine for a Travel. Booking.TicketReciept' object which responds 
by loading and executing (4) an Initiator role component. This Initiator role component 
sends a request message (5) to the Respondent role component of the finance 
provider agent FPA, which performs the booking process. Upon completion of the 
booking process a response message (6) is sent back to the Initiator role component of 

35 the Information Provider Agent (IPA) (i.e. to the ticket provider agent TPA (A)) 
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containing the Travel. Booking.TicketRecipent object. This object is then given (7) to 
the Respondent role component of ticket provider agent TPA (A) by the co-ordination 
engine. To complete phase two of the IP the Respondent role component sends a 
confirmation message (8) back to the Initiator role component of the ticket provider 
5 agent TPA. 

Phase three: The Initiator role component's GUI then allows the user to book transport 
to the airport if they wish. If the user chooses to book transport, then the Initiator role 
component sends a request (9) message to the Respondent role component. A 
1 0 response message (1 0) is then sent back to the Initiator role component. 

Now consider the case where an Information Provider Agent (IPA) (in this embodiment 
a ticket provider agent (TPA) (A)) is unable to fulfil the service request. This is shown 
in the lower portion of Figure 8B. In such a situation, the Information Consumer Agent 

15 (ICA) (in this embodiment a ticket consumer agent TCA ) is forced to locate another 
Information Provider Agent (IPA) which is achieved by contacting the nearest 
Information Mediator Agent (IMA). In this scenario there is only one other ticket 
provider agent (IPA), in this embodiment provided by ticket provider agent (TPA) (B). 
Once the Information Consumer Agent (ICA) locates Information Provider Agent (IPA) 

20 (B) via the Information Mediator Agent (IMA), it will complete the C-COM installation 
steps (described hereinabove with reference to Figure 4). The Initiator role component 
of the Information Provider Agent (IPA) (B) employs a different Interaction Protocol (IP) 
to the previous Initiator role component of Information Provider Agent (IPA) (A). A four- 
phase Interaction Protocol (IP) is used by the Initiator role component of Information 

25 Provider Agent (IPA) (B). Phases one and two are similar to the previously discussed 
IP with the exception that the Respondent role component of Information Provider 
Agent (IPA) (B) internally processes the airfare booking. 

Phases three and four are described below: 

30 

Phase three: Once the user has booked their airfare the Initiator role component's GUI 
allows the user to select their preferred seating position. Once selected, a request 
message (5) is sent to the Respondent role component of ticket provider agent TPA 
(B), which is followed by a response message (6). 
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Phase four: The final phase of the Interaction Protocol (IP) involves the selection of 
food for the flight. The Initiator role component's GUI allows the user to indicate their 
food choice. A request message (7) is sent to the Respondent role component of ticket 
provider agent TPA (B). The Respondent role component takes the users food choice 
5 and requests a Travel. Booking. FoodReceipt' object from the local co-ordination 
engine. The co-ordination engine loads (8) an Initiator role component to fulfil this 
request. The Initiator role component then sends a request message (9) to the 
corresponding Respondent role component located in a food provider agent (FPA). The 
Respondent role component responds (10), and the Initiator role component of ticket 
10 provider agent TPA (B) passes the request object (11) back to the co-ordination 
engine. The Respondent role component then sends a confirmation message (12) back 
to the Initiator role component of the ticket consumer agent TCA. 

The component-based multi-agent architecture thus enables open and flexible 
15 information exchange among multiple agents. The C-COM plug & play software 
component comprises two or more role components which abstract and hide all the 
details of interactions among the participating roles. In a multi-agent system (MAS) 
architecture (CcoMaa) within which the C-COM service components are deployed, an 
agent is able to participate in new services that have been added to an existing agent 
20 society even if the agent isn't initially able to recognise the interaction protocol (IP) or 
language used by the new services. By installing the appropriate role component using 
a C-COM service component an agent is able to take advantages of these new 
services, even if they have no previous understanding of the Interaction Protocol and 
Conversation Policy required for the new service interactions.. 

25 

Participating agents in the CCoMaa should have the same level of understanding of 
the ontology items used for their interactions. If an Information Provider Agent (I PA) 
requires an additional unknown ontology item from an Information Consumer Agent 
(ICA), the Information Provider Agent (IPA) is forced to provide a GUI component that 
30 is then used to retrieve the unknown ontology items from the ICA's human user. It is 
possible to increase an ICA's autonomy by providing instead an ontology derivation 
rule which guides an ICA as to how the unknown ontology item can be derived from 
known ontology items. 
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The use of C-COM can prevent an ICA from learning the social interactions used with 
the other participating agents as a C-COM hides all the interaction details. An extended 
component description can be provided to resolve this by detailing the IP employed by 
the C-COM. 

5 

It will be appreciated by those skilled in the art that many aspects of the invention can 
be implemented in either software and/or hardware and that the spirit of the invention is 
intended to cover embodiments in any combination of software and/or hardware as 
appropriate, and that software elements of the invention can be provided by a 

10 computer product which may comprise a signal communicated over a communications 
network, for example, as a downloadable suite of one or more computer programs, 
and/or as a suite of one or more computer programs provided on a computer readable 
data carrier, which are able to execute the invention when loaded and run on an 
appropriate device. The invention can also be provided by a carrier having a computer 

15 program stored thereon, the computer program being executable on a terminal so as to 
cause the terminal to operate the invention. 

As those skilled in the art will find apparent, the multi-agent system (MAS) provided by 
the invention enables individual components of the MAS provided by applications 
20 installed on different platforms providing a distributed computing environment to 
interaction with one or more other applications supported by remotely located 
platforms. The platforms may support applications in the client and/or service domain. 

Any pseudo-code described herein is provided as is and without any guarantee as to 
25 its completeness or accuracy. 

The text of the abstract repeated below is hereby incorporated into the description: 
A service component enables client/server interactions even when information on the 
content language and/or interaction protocol required for the service the client agent 
30 has requested from the service agent is not known a priori The service component 
has a generic structure comprising a plurality of role components which perform the 
service interaction between the client agent and the server agent and which provide 
sufficient information on the interaction requirements to enable the requested service to 
be provided. 



